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REMARKS 

Claims 1, 57-69. and 71-78 arc pending in this patent application. Reconsideration of 
the rejections in view of the remarks below is requested. 

Claims 1, 57-61, 63-69, 71, 73, 74 and 76-78 stand rejected under 35 U.S.C. § 102(e) 
as being anticipated by United States patent no. 5,815,657 to Williams et al. ("Williams"). 
The rejection is respectfully traversed. 

Applicant respectfully submits that the cited portions of Williams fail to disclose. 
inter alia, obtaining electronic signals representing a request for transactional financial 
assurance with respect to electronic infrastructure used m or w ith a transaction invoh ing the 
subscriber and determining whether to provide the requested transactional financial assurance 
based on at least the subscriber assurance, as recited in claim 1. 

For example, the cited portions of Williams appear to be silent as to transactional 
financial assurance with respect to electronic infrastructure used in or with a transaction. As 
non-limiting examples, the cited portions of Williams appear to be silent as to providing 
assurance regarding the authenticity of an electronic certificate, assurance regarding the 
accuracy of an electronic certificate, or assurance regarding the validity of an electronic 
certificate. As discussed previously, the system of Williams appears merely to facilitate 
payment between a consumer and a merchant. 

The Office Action, at page 3. argues that "[i]n Williams at col. 1 1 lines 31-38, the 
certificates utilized by consumers in transactions are taught as X.500 type certificates. As 
such, these certificates will contain a digital signature utilized in the process of verifying the 
certificate taught at col. 13 line 40 through col. 14 line 23. This reads on the Applicant's 
feature of assurance of the validity of the certificate." Applicant respectfully disagrees. The 
X.500 type certificate of a consumer in the transactions referred to in the cited portions of 
Williams is an embodiment of the "subscriber assurance" recited in the claim 1 . The X.500 
type certificate referred to there is essentially the same as the X.509 type certificate referred 
to in the background of Applicant's application. See, e.g., page 2, line 20 to page 3, line 8 of 
Applicant's specification ("Digital signature certificates (sometimes also called public key 
certificates or simply certificates) meet this need. These certificates are generally issued by 
trusted third parties known as certification authorities (CAs) and they certify (1) that the 
issuing certification authority has identified the subject of the certificate (often according to 
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specifications delineated in a certification practice statement), and (2) that a specified public 
key (in the certificate) corresponds to the a private key held by the subject of the certificate. 
A structure for public-key certificates is included in the X.509 standard cited earlier."). It is 
precisely these kinds of certificates that suffer from deficiencies as disco\ered by Applicant 
and addressed by one or more embodiments of the invention. See, e.g., page 6. line 13 to 
page 8, line 21 of Applicant's specification. 

Moreover, it is clear that the consumer X.500 type certificate of the cited portions of 
Williams, or any signature in such consumer X.500 type certificate, does not match the claim 
language. Indeed, the Office Action appears to inconsistently rely on the X.500 type 
certificate as the recited subscriber assurance. See, e.g.. Office Action, page 4. lines 8-11. 

For example, there is no apparent disclosure of a request for the consumer X.500 type 
certificate in Williams; there is no showing of some aspect of the Williams system essentially 
asking for the consumer X.500 type certificate. Further, there is no apparent disclosure that 
the consumer X.500 type certificate provides transactional financial assurance with respect to 
electronic infrastructure used in or with a transaction involving the subscriber; rather, the 
consumer X.500 certificate is putatively intended to provide assurance regarding only the 
consumer him or herself. There is also no apparent disclosure of any determining whether to 
provide the consumer X.500 certificate, let alone doing so based on at least a subscriber 
assurance (e.g., a consumer X.500 certificate as in Williams). 

Similarly, there is no apparent disclosure of a request for a digital signature in the 
consumer X.500 type certificate in Williams; there is no showing of some aspect of the 
Williams system essentially asking for the digital signature in the consumer X.500 type 
certificate in Williams. Indeed, there is no mention of signature m Williams at all except that 
Williams merely discloses at col. 15, lines 6-8 that there is signature support in the Williams 
system and at col. 16, lines 59-61 that the merchant provides a digitally signed receipt. 
Further, there is no apparent disclosure that a digital signature in the consumer X.500 type 
certificate provides transactional financial assurance with respect to electronic infrastructure 
used in or with a transaction involving the subscriber. For example, there is no indication in 
the cited portions of Williams that a digital signature (regarding which Williams is essentially 
silent) provides financial assurance. As noted in Applicant's specification, a digital signature 
provides no assurance as it can be forged or otherwise unauthorized. There is also no 
apparent disclosure of any determining whether to provide a digital signature in the consumer 
X.500 type certificate, let alone doing so based on at least a subscriber assurance (e.g.. a 
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consumer X. 500 certificate). 

The Office Action also indicates that Williams teaches that "both merchant and 
consumer certificates are sent for verification as part of a request message." However, that is 
nothing like what claim 1 recites. Claim 1 recites a request for transactional financial 
assurance with respect to electronic infrastructure used in or with a transaction involving the 
subscriber. So. even if arguendo the recited transactional financial assurance is the merchant 
and'or consumer certificates in Williams (which Applicant contends they are not at least for 
the reasons presented herein), then respectfully it doesn't make sense that they would be "part 
of a request message". Rather they w ould be the desired product of a request for them. 

The Office Action also refers to Figure 5 and col. 13, line 40 to col. 14, line 23 of 
Williams as allegedly disclosing obtaining electronic signals representing a request for 
transactional financial assurance with respect to electronic infrastructure used in or with a 
transaction involving the subscriber. For example, page 4 of the Office Action argues that 
Williams discloses at "(col. 13 line 40 through col. 14 line 23: the Payment Manager receives 
the request for transactional assurance (i.e.. authorization to pay or payment) from the 
merchant, and receives certificate information from the user (user's wallet manager))". Thus, 
those cited portions of Williams appear merely to disclose one or more certificates used in the 
process of completing a payment request. Thus, while the cited portions of Williams might 
disclose completing a payment request based on a certificate, the cited portions of Williams 
do not appear to provide, for example, any financial assurance with respect to a certificate (or 
with respect to some other electronic infrastructure used in or with a transaction involving the 
subscriber). The described certificates, and their verification mechanisms if any, in the 
Williams system may be entirely fraudulent. There appears to be no discussion of, for 
example, provision of a financial assurance with respect to any of those certificates (or with 
respect to some other electronic infrastructure used in or with a transaction involving the 
subscriber). As noted in Applicant's specification, the conventional certificate system 
discussed in Williams has various shortcomings and leaves, for example, someone relying on 
a certificate vulnerable. See, e.g., pages 6-8 of Applicant's specification. The present claimed 
invention provides a mechanism to provide assurance regarding electronic infrastructure, 
such as a certificate, used in or with a transaction involving the subscriber. 

Claims 57-61 and 76 depend from claim 1 and are, therefore, patentable for at least 
the same reasons provided above related to claim 1, and for the additional features recited 
therein. 
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For similar reasons as provided above. Applicant respectfully submits that the cited 
portions of Williams fail to disclose a computer program product, embodied in a computer- 
readable media, comprising instructions for causing a computer to effect a method of 
managing reliance in an electronic transaction system as recited in claim 63. For example. 
Applicant submits that the cited portions of Williams fail to disclose causing electronic 
signals representing the reliance request message to be sent to a reliance server requesting a 
transactional financial assurance for the aspect of the transaction upon which the relying 
party intends to rely, the transactional financial assurance including transactional financial 
assurance with respect to electronic infrastructure used in or with the transaction as recited in 
claim 63. 

Claims 64-67 and 77 depend from claim 63 and are, therefore, patentable for at least 
the same reasons provided above related to claim 63, and for the additional features recited 
therein. 

For similar reasons as provided above, Applicant respectfully submits that the cited 
portions of Williams fail to disclose a computer program product, embodied in a computer- 
readable media, comprising instructions for causing a computer to effect a method of 
managing reliance in an electronic transaction system as recited in claim 68. For example, 
Applicant submits that the cited portions of Williams fail to disclose determining whether to 
provide transactional financial assurance with respect to electronic infrastructure used in or 
with the transaction based on the reliance request message as recited in claim 68. 

Claims 69, 71, 73, 74 and 78 depend from claim 68 and are, therefore, patentable for 
at least the same reasons provided above related to claim 68, and for the additional features 
recited therein. 

Because the cited portions of Williams fail to disclose the claimed subject matter of 
claims 1, 57-61, 63-69, 71, 73, 74 and 76-78, Applicant respectfully requests that the 
rejection under 35 U.S.C. § 102(e) of claims 1, 57-61, 63-69, 71, 73, 74 and 76-78 based on 
Williams be withdrawn and the claims be allowed. 

All rejections having been addressed, it is respectfully submitted that the present 
application is in condition for allowance. If questions relating to patentability remain, the 
examiner is invited to contact the undersigned to discuss them. 
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Should any fees be due. please charge them to our deposit account no. 03-3975. under 
our order no. 061047/0268225. The Commissioner for Patents is also authorized to credit am 
over payments to the above-referenced deposit account. 

Respectfully submitted, 

PILLSBURY W.1NTHROP SHAW PITT MAN LLP 



Jean-Paul Hoffman \ 
Reg. No. 42.663 . 
Teh No. 703-770-7754 
Fax No. 703-770-7901 

May 26, 2010 
P. O. Box 10500 
McLean, VA 22102 
(703) 770-7900 
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